Hi @bendemboski! Great catch. We tried to refactor this code once and we failed so any fixes to it are hard to test.

I tried to add a unit test for this but, due to extensive Symbol uses and other tricks I didn't manage to.

Anyway, I've added a reference to this PR to the code so hopefully we could track it in the future.

I tried to add a unit test for this but, due to extensive Symbol uses and other tricks I didn't manage to.

Haha, yeah, me too. I tried for a bit to see if there was a functional problem, where it still existing under _listeningTo would cause it to be called under certain event firing conditions, but couldn't figure that out either. There is a way to actually write automated tests for leaked objects if you run the tests in Electron and use createIDWeakMap (see this article), but that's probably not worth your while to set up unless you find that you're having ongoing/hard to manage issues with memory leaks.

Anyway, glad the code got merged!

Thanks for the article. Yeah, setting up Electron for this might be overkill. We have simple tests that should detect huge memory leaks using window.performance and window.gc() (Chrome must be run with -js-flags="--expose-gc"). But this method is not precise, and we detect only bigger leaks with this method.